Helpfeel Tech Conf 2024 午後の部
13:20-14:00 Helpfeel開発部のいまと未来2024akiroom.icon
その話もする
テクノロジー
知識を実用する
アート
美しさ
UIの美しさ、インターフェースの美しさ
美しさも気にしてるんだyosider.icon
情熱、ひらめき、共感
デザイン
自分たちの課題から抽象化して物事を捉える
定石のしゅはり
俯瞰
クラフト
「私AだからXには関わらない」と壁をつくるのではなく、一緒に作っていく
おおむね維持できている
いままでフルスタックエンジニアの求人を出していたが、違和感があった
複数領域の専門性を高めてプロダクト開発
生成AIを軸に新しいプロダクトや機能を生み出す
外部環境による変化への対応がキー
外部環境：社内外のステークホルダーの増加
ユーザーの増加
インフラ規模が巨大
株主の増加
従業員の変化
今は185人
指数関数的に増加している
増加するステークホルダーという課題にふまえて、責任を果たすハッカー集団を目指す
もともとは株主への説明のために作った図
開発者自身が3つの視点を持つ
1. ソリューション新規開発
開発者が経営者の帽子をかぶる
組織として何に貢献したいか
「仮想通貨のスキャルピングに人生を賭けていないのはなぜですか？」の答え
顧客要望の実現化
開発者が顧客の帽子をかぶる
素人発想玄人実行
ビルドトラップを避ける
自分が使っていないものを想像できない
例：アクティブディレクトリを使っていないから、対応できません
プロダクトの磨き上げ
開発者が開発者の帽子をかぶる
専門性から生まれる気づきでプロダクトを改善する
UI/UX向上
ほとんどのユーザーは指摘せずサイレント離脱する
これよくいわれてそうなことだtakker.icon
仮に指摘したとしても、それはほとんど間違っている
セキュリティ対策
ユーザーは問題が起きるまで気づかない
バグ修正もしっかり
これら3つの視点を全部もつ
どうするか
各領域にリーダーを置く？
領域ごとの型化？
これらがどうなったか、来年紹介する
制約と限界のなかでベストを尽くすことから始める
フレームワークやモデルは有用なフィクション
現実から有用なフィクションを取り出して試す
現在の開発部
ただこれはAIを否定している企業と捉えられてしまうことがあったので、新しいコンセプトを作った
リソースに偏りがある
scrapboxがほとんどいない
Gyazo
500TB～600TB/月を越える大規模インフラ
マルチプラットフォーム対応
Scrapbox
1500万ページ突破
プロダクトサイクル
Gyazo: 成熟期
次のグロースを模索
海外ユーザーがほとんどなので、円安の影響をモロに受ける
Cosense: 導入期
PMF前夜
まだ導入期だったんだtakker.icon
Helpfee: 成長期
事業成長の途中
コーポレートIT
上場目指してるの知らなかったtakker.icon
昔
Nota Inc.は米国法人だった
スクボ使わなくなったのは残念に思うtakker.icon
検討はしてるみたい
プロダクト開発三本の矢
13:59:25 おわり
14:00-14:20 休憩
歩き回るもののあまりはなせず
挙動不審と化しているtakker.icon
14:20-14:40 Cosenseへのリブランディングについて語ります sawachin.icon ben akikoy yado
Cosenseのリブランディングの紆余曲折や外部パートナーとの協力、社名・ロゴの意味、ブランディングの進め方について深く掘り下げ、Cosenseの哲学に触れる
今日はけっこうCosenseの話してる
名前「Cosense」は/benfoden/Ben.iconさんが発案した 3000件くらい考えて、そこから絞り込んだ？
最初はcosenseは候補になかったらしい
もう一度考え直したときの候補にcosenseが入っていた？
有力だった他の候補
「CoAhead」？
「いきなり1案に決めました」よりも「3案くらい出して絞り込み」
いきなり1案はうまくいかない。
3回くらいコンサルティング会社に出してもらったがしっくりこない
絶望感
そのあとbenさんから提案がきた
それも数回繰り返し、ようやくcosenseが出てきた
嫌いだったから変えたわけではない
かなり強調してるtakker.icon
社名変更は「やるぞ！」って感じ
scrapbox変更は「やるのか……？」という感じ
名前が決まってからロゴ作成を開始
"table:cosenseはロゴ決定後かtakker.icon
ロゴが全く決まらなかった
ギリギリのギリギリ
それ自体はいい雰囲気だと思う
最終的に合意できたのは奇跡っぽいな
Cosense裏話おもしろいcak.icon
リブランディングに込めた思い
組織でも使ってほしいという願いを込めてcosenseとした
14:40-15:00 A デザインとデータで貢献する - 売上向上のためのデザイン施策 takeru
デザインとデータの組み合わせが売上向上にどう貢献するかを具体的な事例と共に紹介し、デザイナーがデータを活用する重要性を強調。デザイナーがデータを活用する際の具体的な手法やツール、成功事例を紹介
デザインの本質はコミュニケーションなので、成果の確認は大切である。
現在Gyazoチームは20件の短期的な売上向上施策を実施中（開発中のものも含む）
そのうち3分の1は成果が出ている。
GyazoのWebAppのメニューが時々変わっているのはこれのためだったのか。種明かし感！mgn901.icon
課題の見つけ方
2種類のデータを両方見る。それを習慣化する。
定量データ
大きなKPI（AU、UP数）、小さなKPI（各施策や機能からのCV）を毎週確認している。
定性データ
定量データの裏には定性データがあるので、定性データを見ることで課題を見つけられるし、説得力にも繋がる。
課題
無料トライアルを経験したユーザーは、しなかったユーザーよりもProに転換しやすい。
なので、Gyazoチームとしては無料トライアルをオンにして欲しいが、オンにしてくれる人が少ない。
原因
ヘルプのトラヒックを分析したら、無料トライアルは課金されると勘違いされていることがわかった。
解決策
無料トライアル誘導の文言を改善
Gyazo proに無料トライアルあるの知らなかったcak.icon
良い施策の3要素：どれか一つでも欠けると失敗してしまう。
1. どれくらいの効果を見込めるか
2. 実装コスト
3. ユーザー目線：例えばバナーを出しまくったりするのは、ユーザーのことを考えていないということ。
Chrome拡張機能のUIにProへの誘導を付けたが、ほとんどProになってくれるユーザーはいなかった。
こちら側からの一方的な情報提供だから失敗。
Gyazoアプリの設定画面にProへの誘導を付けたら、Pro購入数が15% UP
設定画面でGyazo GIFの録画時間を伸ばそうとして諦める人がいることがわかったから実施。
ユーザーが求めている物に対するアプローチなので成功。
効果測定
効果測定をしない施策はやらない方がマシ
ポイント
提案時点で成功とリスクの指標をはっきりさせる。
施策単位の指標を計測する。
施策単位で成功失敗がわかる。
14:40-15:00 B Gyazo 開発 Platform Engineering hiroshi
Gyazo 開発/運用の歴史をざっと振り返り、実践的な細かい TIPS みたいなのを紹介します。現場の雰囲気が伝われば幸いです。
14:43:31 聞いてるtakker.icon
2007年にmasui.iconさんが個人サーバーで開始
perl→PHP→Rails&Go→GKE&Docker
今はほとんどGKEで済んでいる
gyazo.comがRails
i.gyazo.comがGo
gyazoのplatform engineering
CI/CDの話がほとんどだ
なじみない世界なので、用語があんまりわからないtakker.icon
version更新を自動でやる設定など
one-off bachの処理
background jobにすると便利
自分が使わないもののユーザーがほしいものを想像するのが苦手
Cosense/Gyazoは自分で使っているから、こういう開発支援はモチベあがる
15:00-15:20 A 「アクセシビリティを始めたい！」から1年、あれからどうなったのか。出来たこと、出来なかったこと、そして未来へ。/pastak-pub/pastak.icon アクセシビリティを1年間取り組んだ成果と未来への展望を共有。最近の活動や成果を総覧的に語る。
1年経ってたのか。1年って早い……。mgn901.icon
15:05:43 見てるtakker.icon
やっていないとコンペで負ける
やったほうがいいから、やらないと死ぬ時代になった
エンタープライズ対象のプロダクトだとアクセシビリティが必然視されるから始まったのだろうか……mgn901.icon
じゃないらしい。↑は社内でアクセシビリティの取り組みを広げるためのモチベーションであり、/pastak-pub/pastak.iconさんとしてはやりたい気持ちを持ち続けていた。mgn901.icon
目指すところ
当たり前を当たり前に実装したい
次のメガネを作る
キーワード
ボトムアップ
関心のあるメンバー間の取り組みから初めて、広げていく
越境
エンジニアだけに閉じていては限界がある
デザイナー、マーケターetc.にアクセシブルに
サービスにたどり着くためのアクセシビリティが必要だから。
ブログ、プレスリリース、展示会に出すアセット、タクシーのCM、営業資料、……のアクセシビリティ
実際にやったこと
勉強会
freeeやsmartHRが資料を公開している
ここにも勉強会資料として社内Cosenseのキャプチャが登場mgn901.icon
視覚特性のエミュレーション機能がchromeにあるtakker.icon
サービスLP観察会
勉強会をきっかけに開催
デザイナーと一緒に開催
なんの機能か今まで知らなかった
パフォーマンスやSEOも測れますね。mgn901.icon
「Helpfeelオレンジを使うとコントラスト比確保が難しい」
ブランティング側にとっては言葉にできないもどかしさだろうな……mgn901.icon
a11y作業DAY
アクセシビリティ作業を1日中たれ流す
改善PRの提案
<a>と<button>の使い分け
モーダル関連のフォーカス改善
アクセシビリティオフィスアワー
a11yDayは長丁場で大変だったので、2週間に1回、1時間程度にした
アクセシビリティ改善ニュース
今は停滞中
毎月出そうとすると、毎月機能更新を実装しなければならない
課題
アクセシビリティオフィスアワー以外の施策がなかなか継続しない
関心がある人とそれ以外の人の格差を埋めていきたい
アクセシビリティに限らず難しい。mgn901.icon
アクセシビリティに関する知の高速道路を作りたい
継続性と組織とのすりあわせが課題
cosenseは独自UIだからなあtakker.icon
SaaSが社会のアクセシビリティを上げることに貢献するという考え方とてもいい。mgn901.icon
15:00-15:20 B リバースプロキシをやめて運用しやすいLP配信アーキテクチャにしたhata6502.icon リバースプロキシを自力で運用するのは難しい。既存のアーキテクチャを把握しながら、リバースプロキシを剥がしていく過程を解説。トラブル対応やSEOなどへの影響を事前に検討した。
15:20-15:40 休憩
yuta25.iconさんと合流した
2人でshokaiさんのところにいく
二人なら怖くないsta.icon
まさかの布石だった
もともとページ内検索だけで済ますつもりはなく、いろいろ揃ってきたので実装し始めた 15:40-16:00 A Helpfeelの要望管理を支える技術 niboshi
AsanaとCosenseの同期周りを掘り下げ、リリース周知待ちの運用などを紹介
Helpfeelには顧客から要望が来る。
「ExcelでHelpfeelのデータを管理したい」「動画のサムネを0秒時点にしたい（ほぼ原文ママmgn901.icon）」などが来る。 なぜ要望管理をするのか
優先度をつけたい、……
要望管理で何を把握したいのか？
プロジェクトマネジメント観点では、
担当者、状況、予実管理、優先度
各要望に属性を付与したり、フィルタ、ソート、グルーピングして管理している。
プロダクトマネジメント観点では、
ニーズの高い要望、要望の背景、……
要望の周辺知識が欲しい。
「バックログツールでは知識ネットワークを作れないので、これをやるためにCosenseを使う」
Cosense出てくると思ったら出てきた。mgn901.icon
PjMとPdMで視点が違うっていうことが明文化されている！mgn901.icon
CosenseとAsanaの連携をどうやっているのか？ この同期を取る仕掛けは面白そうmeganii.icon
Asanaにはメモを一切書かず、Cosenseに書くとAsanaにCosenseのURLが出るなど
15:40-16:00 B 自律的な開発と部署間連携 balar
部署間の壁を越えて社内の業務改善ツールを作った話。課題や問題点を把握するために取り組んだ事や優先度付けの考え方などを話します。
今まではserverにdeployしてから確認していた
別部署の社内定例に顔を出す
課題の発見よりも、業務内容を知ることが目的
議事録にコメントを書く
要望や困りことはページに切り出して、開発部にすぐ投げれるようにする
入社して数ヶ月たった人と話す機会を作る
どういうところで苦労したか、時間がかかったか聞く
ツールを限定せずにざっくり聞く
どうなると解決になるか一緒に考える
要望をそのまま解決しない
要望の背景を探す
リリースした機能を実際に触ってもらう場を作る
改善をゴールにしない
業務で利用する前に一度経験してもらう
課題の優先付け
どこからやるか
簡単なものから、ではない
判断の基準
performanceをのばすもの
あると便利なもの
github copilotが使える状況など
performanceを下げているもの
ないと困るもの
例：メモ帳で開発しなければならない状況
performanceを下げているものを優先して解決する
本来の業務とは違うところで時間をかけることを、困ることを減らしたい
本質的なことに集中させたいということかtakker.icon
16:00-16:20 A Helpfeel開発チームのオンボーディング yado
フルリモート＆ドキュメント文化のHelpfeel社において、Helpfeel開発チームが実践しているオンボーディングの取り組みを紹介
新しいタスクを実施するまでのオンボーディング
フルリモートでオンボーディング
はじめは、Google Meetを使って口頭で
雑談も交えて、互いのパーソナリティを知るチャンスと捉えている
1. 情報の調べ方・書き方を学ぶ
必要な情報はCosenseにある
どうやってしらべたらよいのかを学んでもらう
全員で情報共有をするという意識を持ってもらう
MTG 中に話したことをドキュメントに残す練習
2. 開発環境の構築
ドキュメント化されている
「これは導入してください」「あとは好きにしてください」がはっきりしている
3. 各主要機能について概要を理解する
知らない用語が多すぎる問題
主要機能についてざっくり説明していく
各機能のCosenseのリンクがあるのでいつでも思い出せる
4. 各主要環境の設定をローカル環境で行う
特に重要な機能についてはローカル環境で動かす
手を動かすことで
5. 本番環境に自分用のデモプロジェクトを作る
顧客提供前の機能を本番環境で確認
閲覧には必ず認証をかける
オンボーディングもドッグフーディング
情報のアップデートを新メンバーと一緒に随時行う
「あぁこれ古くなっているわ」という部分を、画面見ながら一緒に改善できるのっていいよなぁmeganii.icon
PowerPointとかExcelだと後で直すになってしまう
オンボーディングツールと日常業務で使っているツールが同じ
16:00-16:20 B Cosenseチームでの開発の進め方 ohnishi
shokai.iconさん以外の開発風景をはなす
2024-01からは3人体制
shokai,balar, ohnishi
7月にインターンが1人
開発の特徴
相互レビューなし
他の人のはshokai.iconさんがレビューする
理由:
shokai.iconさんの開発速度が速すぎて、他の人がレビューするとそれがボトルネックになってしまう
どういうことなの..wogikaze.iconbsahd.icon
内部実装の知識が少ないというのもある
shokai.iconさんが速いことによる部分もあるので、一般化はできないが。
writeとpreviewを行き来するのが苦手
scrapboxが使えなくなった時のためにPR本体にも説明は書くが、3倍くらい時間がかかる
単体で意味が分かるように書き直すため
開発の具体例
全文検索とかinfoboxも翻訳してあるの？知らなかった。mgn901.icontakker.icon 改善
全文検索翻訳結果は、そのまま下に表示していた
しかし、概要が長いとぱっと見わかりづらい
色々試す
本文と翻訳文を交互に表示
本文の最後に翻訳文
✅本文を全部改行し、その下にそれぞれ翻訳文を入れる
意外とどのパターンでもうまくいった。
うまくいかなかったこと
そこもやるんかい！徹底してるなぁmgn901.icontakker.icon
むずかしそうだなあtakker.icon
じっさい、本文の翻訳だけでもかなりガクガクしてる
草takker.icon
ガクガクってようはスクロール速度が不連続ってことだよねtakker.icon
スムーズにスクロールできればいいのかな
DeepLのAPIからのレスポンスが返ってきた順に訳文を入れると、項目の高さが変わるから（空けておくという手もありそうだがmgn901.icon）
実際cosenseは文字での説明がほとんど
takker.icon個人で使っているUserScriptはなるべくアイコンをいれたりするが、他の人も使いそうなときはなるべく省いたほうがよさそうだ
ちなみに自分がアイコンを使っているのは、スペース削減が目的
16:14:21 あれmgn901.iconさんかなtakker.icon
タイプのタイミングで気づいた
昼くらいからずっとこのページに張り付いてますmgn901.icon
いいはなしtakker.icon
テンプレ構成に従わなくてもいい
この考え方好き。mgn901.icon
一旦型にはめてみて、「これ要らんのでは」と思ったらはずしてみてもいいのではないか
takker.iconはUserScriptを書くときや他の人のコードをいじるとき、要らんツールをがんがん削っていくスタイルだが、それと通じるのを感じた
nextで勝手にdirectoryが作られたり、index.tsが作られたりするやつ
下手にテンプレ使うと、根幹がどうなってるかわからず混乱する
注：cosenseが小規模というのもある
ユーザーに悪影響がない部分はどんどん失敗したほうがいい。
めっちゃよかった
16:20-16:40 A Helpfeelでの新しいプロダクトの生み方と育て方daiiz.icon
新しいプロダクトが生まれる瞬間や育て方、エンジニアドリブンでPMF成功したプロダクト開発の秘話、研究と顧客ニーズに焦点を当てた話
Helpfeelの説明
Helpfeel社で新しいプロダクトが生まれる瞬間
masui.iconさんの発明
Helpfeelは展開ヘルプにCosenseを組み合わせたもの。 ドッグフーディング
開発現場でのニーズの発見
新機能を提案できるエンジニアになるために、
PMFできる領域を探す。専門領域に向き合う。
試作検証を繰り返す
並行して新技術にもキャッチアップする
……
需要だけを狙って作る感じじゃなくて、自分の技術を需要に合わせるという作り方が面白い機能に繋がるんだろうなぁ……。mgn901.icon
お問い合わせフォームと分析機能
問い合わせの分析までをセットで作り込んでいるのがよさそうmeganii.icon
件数の推移を可視化して減少を確認
検索ボリュームの確認
これはクライアントサイドとサーバーサイドのどちらでやっているのだろう？mgn901.icon
インクリメンタル検索
文章の後ろに重きをおいて、話題の遷移に対応する
ユーザーマニュアル検索
「工業製品のPDFマニュアルを検索したい」という要望から
ナレッジの有効活用：PDFは綺麗に作り込まれているのでそのまま使う。
思い切っている。ついついテキスト化したくなってしまう。mgn901.icon
補足的なFAQをPDFではなくCosenseに書ける。
あまりイメージできなかったのだが、Cosenseの検索結果にPDFの内容も含まれるという感じなのだろうかmeganii.icon
研究中の開発ソリューション
質問文生成
FAQドラフト生成
頻出トピック抽出
全文意図予測検索：「ドキュメントさえあればすぐに検索可能になる」を目指したい。
NotebookLMのようなものを連想するが、展開ヘルプ+Cosenseというモデルならではのできる部分もあるのだろうか？mgn901.icon 16:20-16:40 B 地球規模で考えるプロジェクト管理 nishiyama
地球規模のプロジェクトにおけるマネージャーの重要性と役割、歴史的なプロジェクト事例、Gyazoでの活動内容を紹介
壮大な話がはじまりそうtakker.icon
プロジェクト管理はソフトウェアに限定されない
大規模建設工事
地球温暖化対策
SDGs
プロジェクト管理の対象のスケールに制限はない
有給をとって台湾一周プロジェクトした
アジェンダ
プロジェクト管理のさきがけ(おそらく)
現代で言う現場監督の業務日誌
地球規模のプロジェクトは、成果物が数千年にわたって残る
時間や人数の管理が必要
そのツールが業務日誌だった
業務日誌とtodoリスト
gyazoのタスク管理
何を使っているかよりも、継続して繰り返し確認することが大事
ここ大事だと感じたtakker.icon
yessta.icon
僕は「自分が書いたテキスト」の確認でも継続できるのでそれでいい
大半の人はその程度では耐えられないようだ
ここまで
こうかんがえて収集してみるのもよさそうだ
現在地を把握するために外に出す
事例研究
イギリス東インド会社
ワンピース
ナミはなんの役割をしていた？
現在地の特定
今どこにいるかを決める
航海計画策定
これからどうするかを決める
トラブル対処
ここまでのまとめ
航海士の仕事は、間違った方向に進むのを避けること
事例
プレスリリースを目標とした
現状確認
第一段階はすでにクリアしているとわかった
第二段階を得意なエンジニアにお願いした
計画策定
PMは詳しくない
担当エンジニア(現場)のほうが詳しい
ドメイン関係者の話を聞くことが大事
現代的な意義
実は舞踏を通じた国際協調だっのでは？
まとめ
個人的な営みに基礎を置きつつも
この話題sta.iconさんの興味に引っかかりそうtakker.icon
プロデューサーもそうだけど、ビジョン持ってて皆を牽引する何でも屋さん
16:40-17:00 休憩